Skip to content

[HLSL] Make trunct overload tests stricter NFC#2

Closed
joaosaffran wants to merge 1 commit intorefactor/overloads-atan2-ceil-cosfrom
refactor/overload-trunc
Closed

[HLSL] Make trunct overload tests stricter NFC#2
joaosaffran wants to merge 1 commit intorefactor/overloads-atan2-ceil-cosfrom
refactor/overload-trunc

Conversation

@joaosaffran
Copy link
Copy Markdown
Owner

This patch updates trunc overload tests to use -O1 instead of -disable-llvm-passes; also, the checks are updated to match the change accordingly.

This work is part of llvm#138016.

@joaosaffran joaosaffran force-pushed the refactor/overload-trunc branch from 200d7a3 to 7662e0f Compare January 22, 2026 21:29
@joaosaffran joaosaffran deleted the refactor/overload-trunc branch January 22, 2026 23:04
joaosaffran pushed a commit that referenced this pull request Jan 28, 2026
This reverts commit 99fab01.

llc was crashing in kernel-args.ll after this patch:
```
.---command stderr------------
| LLVM ERROR: Cannot select: t3: f32,ch = load<(non-temporal dereferenceable invariant load (s16), align 4, addrspace 7), sext from f16> t0, Constant:i32<36>, undef:i32
| In function: f16_arg
| PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
| Stack dump:
| 0.	Program arguments: /b/ml-opt-devrel-x86-64-b1/build/bin/llc -mtriple=r600 -mcpu=redwood
| 1.	Running pass 'Function Pass Manager' on module '<stdin>'.
| 2.	Running pass 'Unnamed pass: implement Pass::getPassName()' on function '@f16_arg'
|  #0 0x0000561402607438 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x81a7438)
|  #1 0x0000561402604b75 llvm::sys::RunSignalHandlers() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x81a4b75)
|  #2 0x00005614026081b1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
|  llvm#3 0x00007f55eb45a050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050)
|  llvm#4 0x00007f55eb4a8eec (/lib/x86_64-linux-gnu/libc.so.6+0x8aeec)
|  llvm#5 0x00007f55eb459fb2 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bfb2)
|  llvm#6 0x00007f55eb444472 abort (/lib/x86_64-linux-gnu/libc.so.6+0x26472)
|  llvm#7 0x0000561402567005 llvm::report_fatal_error(llvm::Twine const&, bool) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x8107005)
|  llvm#8 0x00005614023e7ba7 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f87ba7)
|  llvm#9 0x00005614023e6a7d llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f86a7d)
| llvm#10 0x00005614023dae94 llvm::SelectionDAGISel::DoInstructionSelection() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f7ae94)
| llvm#11 0x00005614023d9e6a llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f79e6a)
| llvm#12 0x00005614023d7b5e llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f77b5e)
| llvm#13 0x00005614023d4c30 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f74c30)
| llvm#14 0x00005614023d22e0 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f722e0)
| llvm#15 0x0000561401611793 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x71b1793)
| llvm#16 0x0000561401b790e5 llvm::FPPassManager::runOnFunction(llvm::Function&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x77190e5)
| llvm#17 0x0000561401b80f72 llvm::FPPassManager::runOnModule(llvm::Module&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7720f72)
| llvm#18 0x0000561401b79b56 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7719b56)
| llvm#19 0x00005613ff4858f4 compileModule(char**, llvm::SmallVectorImpl<llvm::PassPlugin>&, llvm::LLVMContext&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&) llc.cpp:0:0
| llvm#20 0x00005613ff482ed3 main (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x5022ed3)
| llvm#21 0x00007f55eb44524a (/lib/x86_64-linux-gnu/libc.so.6+0x2724a)
| llvm#22 0x00007f55eb445305 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27305)
| llvm#23 0x00005613ff47ea21 _start (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x501ea21)
`-----------------------------
```
joaosaffran pushed a commit that referenced this pull request Feb 3, 2026
…lvm#178069)

Kernel panic is a special case, and there is no signal or exception for
that so we need to rely on special workaround called `dumptid`.
FreeBSDKernel plugin is supposed to find this thread and set it manually
through `SetStopInfo()` in `CalculateStopInfo()` like Mach core plugin
does.

Before (We had to find and select crashed thread list otherwise thread 1
was selected by default):
```
➜ sudo lldb /boot/panic/kernel -c /var/crash/vmcore.last
(lldb) target create "/boot/panic/kernel" --core "/var/crash/vmcore.last"
Core file '/var/crash/vmcore.last' (x86_64) was loaded.
(lldb) bt
* thread #1, name = '(pid 12991) dtrace'
  * frame #0: 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015882f780, flags=259) at sched_ule.c:2448:26
    frame #1: 0xffffffff80bd38d2 kernel`mi_switch(flags=259) at kern_synch.c:530:2
    frame #2: 0xffffffff80c29799 kernel`sleepq_switch(wchan=0xfffff8014edff300, pri=0) at subr_sleepqueue.c:608:2
    frame llvm#3: 0xffffffff80c29b76 kernel`sleepq_catch_signals(wchan=0xfffff8014edff300, pri=0) at subr_sleepqueue.c:523:3
    frame llvm#4: 0xffffffff80c29d32 kernel`sleepq_timedwait_sig(wchan=<unavailable>, pri=<unavailable>) at subr_sleepqueue.c:704:11
    frame llvm#5: 0xffffffff80bd2e2d kernel`_sleep(ident=0xfffff8014edff300, lock=0xffffffff81df2880, priority=768, wmesg="uwait", sbt=2573804118162, pr=0, flags=512) at kern_synch.c:215:10
    frame llvm#6: 0xffffffff80be8622 kernel`umtxq_sleep(uq=0xfffff8014edff300, wmesg="uwait", timo=0xfffffe0279cb3d20) at kern_umtx.c:843:11
    frame llvm#7: 0xffffffff80bef87a kernel`do_wait(td=0xfffff8015882f780, addr=<unavailable>, id=0, timeout=0xfffffe0279cb3d90, compat32=1, is_private=1) at kern_umtx.c:1316:12
    frame llvm#8: 0xffffffff80bed264 kernel`__umtx_op_wait_uint_private(td=0xfffff8015882f780, uap=0xfffffe0279cb3dd8, ops=<unavailable>) at kern_umtx.c:3990:10
    frame llvm#9: 0xffffffff80beaabe kernel`sys__umtx_op [inlined] kern__umtx_op(td=<unavailable>, obj=<unavailable>, op=<unavailable>, val=<unavailable>, uaddr1=<unavailable>, uaddr2=<unavailable>, ops=<unavailable>) at kern_umtx.c:4999:10
    frame llvm#10: 0xffffffff80beaa89 kernel`sys__umtx_op(td=<unavailable>, uap=<unavailable>) at kern_umtx.c:5024:10
    frame llvm#11: 0xffffffff81122cd1 kernel`amd64_syscall [inlined] syscallenter(td=0xfffff8015882f780) at subr_syscall.c:165:11
    frame llvm#12: 0xffffffff81122c19 kernel`amd64_syscall(td=0xfffff8015882f780, traced=0) at trap.c:1208:2
    frame llvm#13: 0xffffffff810f1dbb kernel`fast_syscall_common at exception.S:570
```

After:
```
➜ sudo ./build/bin/lldb /boot/panic/kernel -c /var/crash/vmcore.last
(lldb) target create "/boot/panic/kernel" --core "/var/crash/vmcore.last"
Core file '/var/crash/vmcore.last' (x86_64) was loaded.
(lldb) bt
* thread llvm#18, name = '(pid 5409) powerd (crashed)', stop reason = kernel panic
  * frame #0: 0xffffffff80bc6c91 kernel`__curthread at pcpu_aux.h:57:2 [inlined]
    frame #1: 0xffffffff80bc6c91 kernel`doadump(textdump=0) at kern_shutdown.c:399:2
    frame #2: 0xffffffff804b3b7a kernel`db_dump(dummy=<unavailable>, dummy2=<unavailable>, dummy3=<unavailable>, dummy4=<unavailable>) at db_command.c:596:10
    frame llvm#3: 0xffffffff804b396d kernel`db_command(last_cmdp=<unavailable>, cmd_table=<unavailable>, dopager=true) at db_command.c:508:3
    frame llvm#4: 0xffffffff804b362d kernel`db_command_loop at db_command.c:555:3
    frame llvm#5: 0xffffffff804b7026 kernel`db_trap(type=<unavailable>, code=<unavailable>) at db_main.c:267:3
    frame llvm#6: 0xffffffff80c16aaf kernel`kdb_trap(type=3, code=0, tf=0xfffffe01b605b930) at subr_kdb.c:790:13
    frame llvm#7: 0xffffffff8112154e kernel`trap(frame=<unavailable>) at trap.c:614:8
    frame llvm#8: 0xffffffff810f14c8 kernel`calltrap at exception.S:285
    frame llvm#9: 0xffffffff81da2290 kernel`cn_devtab + 64
    frame llvm#10: 0xfffffe01b605b8b0
    frame llvm#11: 0xffffffff84001c43 dtrace.ko`dtrace_panic(format=<unavailable>) at dtrace.c:652:2
    frame llvm#12: 0xffffffff84005524 dtrace.ko`dtrace_action_panic(ecb=0xfffff80539cad580) at dtrace.c:7022:2 [inlined]
    frame llvm#13: 0xffffffff840054de dtrace.ko`dtrace_probe(id=88998, arg0=14343377283488, arg1=<unavailable>, arg2=<unavailable>, arg3=<unavailable>, arg4=<unavailable>) at dtrace.c:7665:6
    frame llvm#14: 0xffffffff83e5213d systrace.ko`systrace_probe(sa=<unavailable>, type=<unavailable>, retval=<unavailable>) at systrace.c:226:2
    frame llvm#15: 0xffffffff8112318d kernel`syscallenter(td=0xfffff801318d5780) at subr_syscall.c:160:4 [inlined]
    frame llvm#16: 0xffffffff81123112 kernel`amd64_syscall(td=0xfffff801318d5780, traced=0) at trap.c:1208:2
    frame llvm#17: 0xffffffff810f1dbb kernel`fast_syscall_common at exception.S:570
```
joaosaffran pushed a commit that referenced this pull request Mar 11, 2026
`SE.getUMaxExpr` causes assertion failure due to type mismatch here:


https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/LoopAccessAnalysis.cpp#L253

Running `opt -S -p loop-vectorize -debug-only=loop-vectorize
llvm/test/Analysis/LoopAccessAnalysis/type-mismatch-in-scalar-evolution.ll
` without the changes made in LoopAccessAnalysis.cpp causes assertion
failure.
Attaching the stack dump for reference:
```
LV: Checking a loop in 'loop_contains_store_assumed_bounds' from input.ll
LV: Loop hints: force=? width=4 interleave=0
LV: Found a loop: for.body
LV: Found an induction variable.
opt: /home/kshitij/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:3918: const llvm::SCEV* llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<const llvm::SCEV*>&): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "Operand types don't match!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0.	Program arguments: opt -S -passes=loop-vectorize -debug-only=loop-vectorize -force-vector-width=4 -disable-output input.ll
1.	Running pass "function(loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>)" on module "input.ll"
2.	Running pass "loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>" on function "loop_contains_store_assumed_bounds"
 #0 0x000058ee97c5e652 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/opt+0x4f44652)
 #1 0x000058ee97c5af0f llvm::sys::RunSignalHandlers() (/usr/local/bin/opt+0x4f40f0f)
 #2 0x000058ee97c5b05c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 llvm#3 0x00007c49d4c45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330)
 llvm#4 0x00007c49d4c9eb2c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 llvm#5 0x00007c49d4c9eb2c __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 llvm#6 0x00007c49d4c9eb2c pthread_kill ./nptl/pthread_kill.c:89:10
 llvm#7 0x00007c49d4c4527e raise ./signal/../sysdeps/posix/raise.c:27:6
 llvm#8 0x00007c49d4c288ff abort ./stdlib/abort.c:81:7
 llvm#9 0x00007c49d4c2881b _nl_load_domain ./intl/loadmsgcat.c:1177:9
llvm#10 0x00007c49d4c3b517 (/lib/x86_64-linux-gnu/libc.so.6+0x3b517)
llvm#11 0x000058ee98003fdb llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*>&) (/usr/local/bin/opt+0x52e9fdb)
llvm#12 0x000058ee98004507 llvm::ScalarEvolution::getUMaxExpr(llvm::SCEV const*, llvm::SCEV const*) (/usr/local/bin/opt+0x52ea507)
llvm#13 0x000058ee980dc728 llvm::getStartAndEndForAccess(llvm::Loop const*, llvm::SCEV const*, llvm::Type*, llvm::SCEV const*, llvm::SCEV const*, llvm::ScalarEvolution*, llvm::DenseMap<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>, llvm::DenseMapInfo<std::pair<llvm::SCEV const*, llvm::Type*>, void>, llvm::detail::DenseMapPair<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>>>*, llvm::DominatorTree*, llvm::AssumptionCache*, std::optional<llvm::ScalarEvolution::LoopGuards>&) (/usr/local/bin/opt+0x53c2728)
llvm#14 0x000058ee9814008b llvm::isDereferenceableAndAlignedInLoop(llvm::LoadInst*, llvm::Loop*, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::AssumptionCache*, llvm::SmallVectorImpl<llvm::SCEVPredicate const*>*) (/usr/local/bin/opt+0x542608b)
llvm#15 0x000058ee9a0fa1ca llvm::LoopVectorizationLegality::canUncountableExitConditionLoadBeMoved(llvm::BasicBlock*) (/usr/local/bin/opt+0x73e01ca)
llvm#16 0x000058ee9a0faee0 llvm::LoopVectorizationLegality::isVectorizableEarlyExitLoop() (/usr/local/bin/opt+0x73e0ee0)
llvm#17 0x000058ee9a104678 llvm::LoopVectorizationLegality::canVectorize(bool) (/usr/local/bin/opt+0x73ea678)
llvm#18 0x000058ee9a08c953 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/usr/local/bin/opt+0x7372953)
llvm#19 0x000058ee9a090e21 llvm::LoopVectorizePass::runImpl(llvm::Function&) (/usr/local/bin/opt+0x7376e21)
llvm#20 0x000058ee9a0914e0 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x73774e0)
llvm#21 0x000058ee99e419a5 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) PassBuilderPipelines.cpp:0:0
llvm#22 0x000058ee97f18905 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x51fe905)
llvm#23 0x000058ee995d70d5 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) AMDGPUTargetMachine.cpp:0:0
llvm#24 0x000058ee97f17051 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd051)
llvm#25 0x000058ee995d7775 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) AMDGPUTargetMachine.cpp:0:0
llvm#26 0x000058ee97f1783d llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd83d)
llvm#27 0x000058ee9c153909 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool, bool) (/usr/local/bin/opt+0x9439909)
llvm#28 0x000058ee97c3f380 optMain (/usr/local/bin/opt+0x4f25380)
llvm#29 0x00007c49d4c2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
llvm#30 0x00007c49d4c2a28b call_init ./csu/../csu/libc-start.c:128:20
llvm#31 0x00007c49d4c2a28b __libc_start_main ./csu/../csu/libc-start.c:347:5
llvm#32 0x000058ee97c309a5 _start (/usr/local/bin/opt+0x4f169a5)
```

This is caused by a type mismatch between
`SE.getSCEV(DerefRK.IRArgValue)` and `DerefBytesSCEV`.
Fixing this by extending them to the wider type.
joaosaffran pushed a commit that referenced this pull request Mar 22, 2026
…D tensor.extract (llvm#187085)

Vectorizing a rank-0 `linalg.generic` whose body contains
`tensor.extract` with data-dependent indices hits the Gather
classification in `getTensorExtractMemoryAccessPattern` because
`isOutput1DVector` returns false for a 0-D result. This produces an
invalid `vector.gather` where operand #2 must be a vector of index
values but gets a scalar `index` instead.

Fix classifies a 0-D result as ScalarBroadcast rather than Gather, and
skips mask generation for 0-D in that path.
joaosaffran pushed a commit that referenced this pull request Mar 30, 2026
…e edge case (llvm#188590)

llvm#186966 was reverted because
the test case triggered a use-of-uninitialized-memory
(https://lab.llvm.org/buildbot/#/builders/94/builds/16379), due to the
include directive omitting a trailing newline. This patch adds a minor
fix to avoid the use-of-uninitialized-memory, and deliberately re-adds
the test case sans trailing newline for regression testing.

MSan report prior to this fix:
```
@@@BUILD_STEP sanitizer logs: stage2/msan_track_origins check@@@
==clang-scan-deps==616960==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x5555599c3300 in isAnnotation /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:131:38
    #1 0x5555599c3300 in setLength /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:152:13
    #2 0x5555599c3300 in clang::Lexer::FormTokenWithChars(clang::Token&, char const*, clang::tok::TokenKind) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Lexer.h:644:12
    llvm#3 0x5555599cf895 in clang::Lexer::LexEndOfFile(clang::Token&, char const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Lexer.cpp:3166:5
    llvm#4 0x555559bb229b in clang::Preprocessor::Lex(clang::Token&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Preprocessor.cpp:916:11
    llvm#5 0x555559aa5365 in __invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__type_traits/invoke.h:90:27
    llvm#6 0x555559aa5365 in invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__functional/invoke.h:29:10
    llvm#7 0x555559aa5365 in operator()<void (clang::Preprocessor::*)(clang::Token &)> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:470:5
    llvm#8 0x555559aa5365 in clang::Preprocessor::CheckEndOfDirective(llvm::StringRef, bool, llvm::SmallVectorImpl<clang::Token>*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:478:5
    llvm#9 0x555559ab96b5 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:2205:7
    ...
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant